SYSTEM AND METHOD FOR FACILITATING ELECTRONIC COMMERCE 
TRANSACTIONS AT AN AUTOMATIC TELLER MACHINE 

FIELD OF THE INVENTION 

[0001] The disclosed invention relates generally to methods and systems for facilitating 
electronic commerce transactions at an automatic teller machine. 
DESCRIPTION OF THE BACKGROUND 

[0002] Automatic teller machines (ATMs) have proUferated throughout the world. As the 
ATM worldwide population continues to grow, the average number of ATM transactions per 
ATM continues to drop. There is, therefore, a need to offer incentives to the population of ATM 
cardholders to make more use of ATMs and to offer owners, operators and deployers of ATMs 
additional sources of revenue to justify investment in ATMs. In addition, electronic commerce 
merchants continue to seek additional revenue opportunities and portals through which to offer 
their products and services. 
SUMMARY OF THE INVENTION 

[0003] The present invention addresses the needs apparent in the prior art by providing systems 
and methods for faciUtating electronic commerce transactions between an ATM user and an 
electronic commerce merchant via a global communications network. 

[0004] The present invention is directed to a method and system for facilitating an electronic 
commerce transaction between an ATM user and an electronic commerce merchant via a global 
communications network. ATM data, which includes transaction data, is received at one or more 
servers remote from the ATM and remote from one or more electronic commerce merchant 
servers. The transaction data is reformatted, at the remote server(s), into a first format that 
enables the transaction data to be utilized by a server located on a global conmiunications 
network. The reformatted transaction data is transmitted over the global communications 
network to the electronic commerce merchant server(s) from the remote server(s). Merchant 
data (generated by the electronic commerce merchant server(s) in response to the reformatted 
transaction data) is received from the electronic commerce merchant at the remote server(s). The 
merchant data is reformatted at the remote server(s) into a second format that enables the 
merchant data to be utihzed by the ATM. The ATM is able to utilize the merchant data without 
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using a browser. The reformatted merchant data is transmitted to the ATM from the remote 
server(s). 

[0005] The present invention is also directed to a method and system for faciUtating 
communication of information via a global communications network related to an electronic 
commerce transaction between an ATM and a server of an electronic commerce merchant. First 
transaction data is received from the electronic commerce merchant at a first server in a first 
format. The first transaction data is capable of being utilized by a server located on the global 
communications network. The first transaction data is reformatted, which includes adding to the 
first transaction data one or more message tags. The message tags instruct the ATM to perform 
one or more functions relating to the electronic conraierce transaction. The reformatted first 
transaction data is transmitted to the ATM. The reformatted first transaction data is capable of 
being utilized by the ATM, without use of a browser. 

[0006] The present invention is fiirther directed to a method and system for facilitating an 
electronic commerce transaction occurring over a global communications network between an 
electronic commerce merchant and a user of an ATM. The ATM is capable of utilizing data 
relating to the transaction without use of a browser. The ATM includes a display screen and one 
or more keys for indicating a selection relating to the transaction. Offer data associated with the 
transaction is formatted for presentation at the ATM. The formatting includes adding one or 
more card tags to the data, associated with one or more cards. The card tags facilitate display of 
transaction information on the display screen and specify content information and layout 
information. The formatting also includes adding a navigation tag to the data. The navigation 
tag faciHtates navigation within cards, between cards or within the global connnunications 
network. The navigation tag fiirther specifies key identification information and key linking 
information. The formatting fiirther includes modifying an input tag associated with the data. 
The input tag facilitates acceptance of one or more input variables from the user and specifies 
variable identification information and variable format information. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0007] The accompanying drawings, wherein like reference numerals are employed to 
designate like parts or steps, are included to provide a further understanding of the invention, are 
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incorporated in and constitute a part of this specification, and illustrate embodiments of the 
invention that together with the description serve to explain the principles of the invention. 
[0008] In the drawings: 

[0009] Figure 1 A illustrates a preferred embodiment of a system for carrying out the methods 
of the invention. 

[0010] Figure IB illustrates a preferred embodiment of a system for carrying out the methods 
of the invention. 

[0011] Figure 2 is a flow chart illustrating a preferred embodiment of a method of facilitating 
an electronic commerce transaction between an ATM and an electronic commerce merchant via 
a global conmiunications network. 

[0012] Figure 3 A is a flow chart illustrating the flow of transaction funds in accordance with a 
preferred embodiment of the present invention. 

[0013] Figure 3B is a flow chart illustrating the flow of transaction funds in accordance with a 
preferred embodiment of the present invention, 

[0014] Figure 4 illustrates a preferred embodiment of a system that supports transaction funds 
flow. 

[0015] Figure 5 illustrates an exemplary ATM screen display. 
[0016] Figure 6 illustrates an exemplary ATM screen display. 
[0017] Figure 7 illustrates an exemplary ATM screen display. 
[0018] Figure 8 illustrates an exemplary ATM screen display. 
[0019] Figure 9 illustrates an exemplary ATM screen display. 
[0020] Figure 10 illustrates an exemplary ATM screen display. 
[0021] Figure 1 1 illustrates an exemplary ATM screen display. 
[0022] Figure 12 illustrates an exemplary ATM screen display. 
[0023] Figure 13 illustrates an exemplary ATM screen display. 

[0024] Figure 14 is a flow chart illustrating a preferred embodiment method of facilitating 
communication of information related to an electronic commerce transaction via a global 
communications network. 

[0025] Figure 15A illustrates reformatted data used to display information on an ATM screen 
in accordance with a preferred embodiment of the present invention. 
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[0026] Figure 15B illustrates the ATM screen display resulting from the reformatted data of 
Figure 15 A. 

[0027] Figure 15C illustrates reformatted data used to display information on an ATM screen 

in accordance with a preferred embodiment of the present invention. 

[0028] Figure 15D illustrates reformatted data communicated from an ATM. 

[0029] Figure 15E illustrates reformatted data used to display information on an ATM screen 

in accordance with a preferred embodiment of the present invention. 

[0030] Figure 15F illustrates the ATM screen display resulting from the reformatted data of 
Figure 15D. 

[0031] Figure 15G illustrates reformatted data communicated from an ATM. 

[0032] Figure 15H illustrates reformatted data representing an exemplary response to the data 

illustrated in Figure 15G. 

[0033] Figure 16 is a flow chart illustrating a preferred embodiment of a method for facilitating 
an electronic conmierce transaction occurring over a global communications network between an 
electronic commerce merchant and a user of an ATM. 

[0034] Figure 17 is a flow chart illustrating a preferred embodiment of steps for formatting 
offer data for ATM presentation. 

[0035] Figures 18A and 18B illustrate reformatted data used to display information on an ATM 

screen in accordance with a preferred embodiment of the present invention. 

[0036] Figure 19 illustrates reformatted data used to display information on an ATM screen in 

accordance with a preferred embodiment of the present invention. 

DETAILED DESCRIPTION 

[0037] Reference will now be made in detail to the preferred embodiments of the present 
invention, examples of which are illustrated in the accompanying drawings. It is to be 
understood that the Figures and descriptions of the present invention included herein illustrate 
and describe elements that are of particular relevance to the present invention, while eliminating, 
for purposes of clarity, other elements. 

[0038] Figure 1 A depicts an exemplary embodiment of a system 100 A for implementing the 
methods of a preferred embodiment of the present invention. The system comprises one or more 
ATMs 108 A, one or more processor servers 106A, one or more service provider servers 104 A, 
and one or more merchant servers 102 of one or more electronic commerce merchants. Service 
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provider server 104A communicates with merchant server 102 via the global communications 
network 110, which is, for example, the Intemet. Further, in some embodiments, service 
provider server 104 A communicates directly with ATM 108 A over network link 120 and with 
processor server 106 A over network link 121 using, for example, a modem. In altemative 
embodiments, service provider server 104A does not communicate with ATM 108 A directly and, 
instead, communicates with ATM 108 A only through processor server 106 A (which may be, in 
some embodiments, a proprietary bank network such as a Base 24 system or other similar 
system) over network links 121 and 122. The servers referred to herein may include any devices 
that serve information to and receive information from computers that connect to them. 
[0039] Figure IB depicts an altemative exemplary embodiment of a system lOOB for 
implementing the methods of a preferred embodiment of the present invention. The system 
comprises one or more ATMs 108B, one or more processor servers 106B, one or more service 
provider servers 104B, and one or more merchant servers 102 of one or more electronic 
commerce merchants, each connected to and commiHiicating with each other via the global 
commxmications network 110 (for example, the Intemet). 

[0040] The ATMs 108 A and 108B in these embodiments accommodate a user who desires to 
make an inquiry of or a purchase from an electronic commerce merchant. The electronic 
commerce merchant is any provider or offeror of goods or services, or one who hosts the 
offering of goods or services of another, that is capable of conducting business over the global 
communications network 110 using merchant server 102, either through a web site or otherwise. 
[0041] The service provider server 104A or 104B is remote from the ATM 108 A or 108B and 
remote from the merchant server 102, meaning that service provider server 104A and 104B does 
not occupy the same physical or virtual space as the ATM 108 A or 108B or merchant server 102, 
In other embodiments, however, service provider server 104 A or 104B is not necessarily remote 
from the ATM 108 A or 108B and/or the merchant server 102. The software residing on service 
provider server 104A or 104B or on ATM 108 A or 108B facilitates transactions among an ATM 
user who enters and receives information at the ATM 108 A or 108B, the merchant that receives 
and provides information through merchant server 102, and a processing network (e.g., a 
verification institution such as VeriSign or a financial institution such as a bank, credit union or 
credit card company) that receives and provides information through processor server 106 A or 
106B. In the preferred embodiment, this software includes one or more of the following 
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components to implement such transactions: an XML parser, Internet interface software, 
encryption software, and ATM interface software. The XML parser converts XML formatted 
data into ATM displayable data. While the preferred embodiments are described herein with 
reference to XML, it will be recognized that the data converted into ATM displayable data in 
accordance with the present invention may be in any format that enables such data to be utilized 
by a server located on a global commimications network, such as the Latemet. The Intemet 
interface software allows interactive commimications between the service provider server 104A 
or 104B and the global conrnumications network 110. The encryption software provides for the 
secure transmission of data between the service provider server 104A or 104B and the ATM 
108 A or 108B. The ATM interface software controls the devices on the ATM 108A or 108B, 
such as the display, keyboard, and printer. Additional fimctionality may be included in some 
embodiments. 

[0042] The service provider server 104A or 104B may, in some embodiments, conduct checks 
to ensure that all ATMs 108 A or 108B and merchant servers 102 within system lOOA or lOOB 
are registered. Service provider server 104 A or 104B may also conduct security checks, which 
will be known to those skilled in the art. In the event there arises a need to add one or more 
ATMs 108 A or 108B or merchant servers 102 to the system 100 A or lOOB, the service provider 
server 104A or 104B may perform this fiinction. Similarly, as one or more ATMs 108 A or 108B 
or merchant servers 102 disassociate with a system such as system lOOA or lOOB, the service 
provider server 104A or 104B may promptly remove them from the system lOOA or lOOB, 
thereby preventing unauthorized transactions involving these disassociated entities. Service 
provider server 104 A or 104B may also maintain a record of transaction data to be used for, 
among other things, reconcihation and settlement activities. 

[0043] As typical ATMs cannot interpret XML or HTML, the programming language currently 
used to create pages hosted on the World Wide Web, software (e.g., the XML parser) residing at 
the service provider server 104 A or 104B reformats the data provided by the merchant server 
102 such that the data can be presented to the user at the ATM 108 A or 108B. The preferred 
embodiments of a method for reformatting this data is described in more detail with reference to 
Figures 15-19. In addition, a typical ATM cannot process large quantities of data at one time. 
Given that the typical electronic commerce transaction carried out, for example, at a personal 
computer involves processing significant quantities of data, the service provider server 104 A or 
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104B may select for reformatting and presentation at the ATM 108A or 108B only a subset of 
the information provided by the merchant server 102. 

[0044] Figure 2 is a flow chart that illustrates a preferred embodiment of a method of 
facilitating an electronic commerce transaction between an ATM user and an electronic 
conmierce merchant via a global conamunications network in accordance with a preferred 
embodiment of the present invention. In particular, Figure 2 describes the flow of data between 
the ATM user and the electronic commerce merchant during a transaction. 
[0045] In step 202, data (including data relating to the transaction) is transmitted from the 
ATM 108 over network link 120 or global commxmications network 110 and received at the 
service provider server 104 A or 104B shown in Figures lA and IB, respectively. In step 204, 
the transaction data is reformatted at the service provider server 104 into a first format that 
allows such data to be utiUzed by a server located on global communications network 110 (such 
as XML). In step 206, the reformatted transaction data is transmitted over the global 
communications network 1 10 to the merchant server 102 from the service provider server 104A 
or 104B. In step 208, merchant data generated in response to the reformatted transaction data is 
received at the service provider server 104A or 104B. In step 210, the merchant data is 
reformatted at service provider server 104A or 104B such that it is capable of being utilized by 
the ATM 108A or 108B. In step 212, the reformatted merchant data is transmitted from the 
service provider server 104A or 104B to the ATM 108 A or 108B over network link 120 (or 
through processor server 106 A via network links 121 and 122) or the global communications 
network 110. 

[0046] In the event the ATM user engaged in a transaction at ATM 108 A or 108B has decided 
to make a purchase, with an associated transaction price, there are several ways in which 
payment for the purchase can be processed in accordance with the invention. Figure 3A is a flow 
chart illustrating a preferred embodiment of a method for processing payment for the purchase. 
This embodiment relates to transactions that do not involve a personal identification number 
("PIN"), such as some credit transactions. In step 302, account data inputted by the user at ATM 
108 A or 108B (by, for example, inserting or swiping a card) is received by, for example, service 
provider server 104A or 104B. In step 304, whether the user's account authorizes the transaction 
is verified with a processing network, for example, processor server 106 A or 106B. Upon 
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verifying that the user's account authorizes the transaction, the transaction is settled in step 306 
by applying the transaction price to the account of the user. 

[0047] In a particular example, in the case of a credit card transaction, the electronic commerce 
merchant may receive the user's account data and verify with a credit card company that the 
user's account authorizes the transaction. In that case, the transaction is settled between the 
credit card company and the electronic commerce merchant. Alternatively, in the case of a credit 
card transaction, transaction facilitator (such as the service provider) may verify with a credit 
card company or with an entity that performs credit verification services that the user's account 
authorizes the transaction. In that case, the transaction is settled between the facihtator and the 
credit verification entity. 

[0048] Figure 3B is a flow chart illustrating another preferred embodiment of a method of 
processing payment for the purchase. This embodiment relates to transactions that are PIN- 
based. In step 322, account data and data associated with a PIN inputted by the user at the ATM 
108 are received by, for example, service provider server 104A or 104B. In step 324, the PIN 
data is verified with a processing network. In step 326, whether the user's account authorizes the 
transaction is verified with the processing network. In some embodiments, step 324 and 326 
may be performed in one step. Upon verifying the PIN data and that the user's account 
authorizes the transaction, the transaction is settled in step 328 by applying the transaction price 
to the account of the user. In a particular example, in the case of a PIN-based debit transaction, a 
facilitator of the transaction (such as the service provider) may verify the PIN data with a 
financial institution (e.g., a bank or credit union). In that case, the transaction is settled between 
the facilitator and the financial institution. 

[0049] The verification steps described above include, but are not necessarily limited to: 
verifying that the PIN data entered is correct for the card entered; verifying that the card is valid; 
verifying that the card has not been reported stolen or cancelled; and verifying that the account 
with which the user intends to associate a transaction is enabled for that transaction. As 
described above, the verification may be performed by a financial institution (such as a bank, 
credit union or credit card company) or some other verification service (such as VeriSign). 
[0050] Figure 4 illustrates one embodiment of a system for supporting the flow of transaction 
funds for a number of different types of transactions. In some embodiments, the transaction 
facilitator and the merchant have agreed that non-PIN based credit transactions will be processed 
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by the merchant. In this case, data obtained from the user at ATM 108 (including the user's 
credit card account information, the user*s choice of product or service, and a transaction price 
associated with the purchase) is transmitted to service provider server 104 (also shown as 104A 
and 104B of Figures 1 A and IB). Service provider server 104 reformats the data and transmits it 
to merchant server 401 (also shown as merchant server 102 of Figures 1 A and IB) over global 
communications network 110. In order to verify that the user's account authorizes the 
transaction, merchant server 401 communicates through credit payment gateway 403 with credit 
jfinancial processor 405 (e.g., a credit card company). Assuming the user's account authorizes 
the transaction, credit financial processor 405 communicates this authorization to merchant 
server 401 through credit payment gateway 403. Credit financial processor 405 also records the 
transaction against the user's accoimt in settlement account database 407. Settlement processor 
410 settles the transaction among the user, the merchant and the credit institution in accordance 
with procedures that will be known to those skilled in the art. 

[0051] In other embodiments, the transaction facilitator and the merchant have determined that 
credit transactions will be processed without involvement by the merchant and, further, that PIN- 
based debit transactions will be processed without involvement by the merchant. In these cases, 
data obtained from the user at ATM 108 (such data including the user's credit/debit card account 
information, data associated with a PIN, the user's choice of product or service, and a transaction 
price associated with the purchase) is transmitted to service provider server 104 (also shown as 
104A and 104B of Figures lA and IB). In order to verify that the user's account authorizes the 
transaction, service provider server 104 communicates through credit/debit payment gateway 
402 with credit/debit financial processor 406. If the transaction is a PIN-based debit transaction, 
the credit/debit financial processor 406 may be part of a banking network that verifies the PIN 
data and that the user's accoxmt authorizes the transaction. Assuming the PIN data can be 
verified and user's account authorizes the transaction, credit/debit financial processor 406 
communicates this authorization to service provider server 104 through credit/debit payment 
gateway 402, Service provider server 104 then presents the pre-authorized transaction to 
merchant server 401, which then continues to process the transaction. If the transaction is a 
credit non-PIN based transaction, the credit/debit financial processor may be a credit card 
company or third party credit verification institution that verifies that the user's account 
authorizes the transaction (the PIN data being discarded in most cases as unnecessary). 
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Assuming the user's account authorizes the transaction, credit/debit financial processor 406 
communicates this authorization to service provider server 104 through credit/debit payment 
gateway 402. Service provider server 104 then presents the pre-authorized transaction to 
merchant server 401 , which then continues to process the transaction. Credit/debit financial 
processor 406 records the transaction against the user's account in settlement account database 
408. Settlement processor 410 settles the transaction among the user, the merchant, the 
bank/credit card company in accordance with procedures known to those skilled in the art. 
[0052] While the user may place an order during the transaction (in which case order 
information is transmitted fi^om the ATM 108 and order confirmation and receipt data is 
returned fi*om the merchant), the user may also simply make an inquiry relating to the 
transaction. For example, a user of an ATM that purports to offer movie ticket information may 
inquire at the ATM as to which movies are pla)dng, where, when and at what price. In this 
embodiment, the user may or may not actually purchase the movie tickets from the ATM. In still 
other embodiments, the transaction data transmitted from the ATM is location information. For 
example, a user of the same ATM may enter at the ATM location information, such as a zip 
code. In response, the ATM may provide the user with movie options at theatres proximate the 
location entered by the user. In other embodiments, location information of the ATM is 
preprogrammed into the ATM or, alternatively, maintained at service provider server. As in the 
previous example, the user may only be seeking information, and may or may not purchase 
movie tickets through the ATM. 

[0053] The electronic commerce transaction options that are presented at the ATM may be the 
same for all users in all cases or may, in some embodiments, vary depending on a number of 
factors. For example, the selections presented to the ATM user may be determined in response 
to some action taken by the ATM user, such as a particular selection made by the user. In 
another embodiment, the offer presented to the ATM user may be specific to the type of card the 
user inserts at the ATM. For example, where a card user receives "points" for making ptirchases 
with his or her card, the offer presented may relate to a conversion of points accrued on the card 
into goods or services. In another example, certain cards may be hmited either by the goods or 
services that can be purchased with the card or by the amount of money that can be charged 
against the card, such as may be the case of a card given to a child by its parent. 
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[0054] The merchant data presented to the ATM user at any point in the process may be data 
that is received from the merchant server 102 in real time as the transaction is unfolding or may 
be data previously received from the merchant server 102 and cached at the server provider 
server 104A or 104B. For example, certain data presented to the ATM user may be the same for 
a number of different types of transactions and does not change based on the user's selection. 
Such static data may be downloaded periodically (for example, in the evening) by the service 
provider server 104A or 104B from merchant server 102 and maintained at service provider 
server 104 A or 104B pending presentation at ATM 108 A or 108B. An example of static data is 
the name of a movie being shown at a particular theatre. Other data presented to the user of 
ATM 108 A or 108B may change based on the user's selections and other inputs. Such dynamic 
data is retrieved from the merchant server 102 by service provider server 104A or 104B in real 
time as the transaction unfolds. One example of dynamic data is current seating availability for a 
particular movie chosen by a user. One advantage of this embodiment is that the static data is 
readily available for presentation to the user at ATM 108 A or 108B without any time delay 
necessitated by having to retrieve data from merchant server 102. 

[0055] The electronic commerce offers presented to users and the merchant data received in 
response to the user's selection at the ATM may be different from the electronic coromerce 
offers and data presented to users of the merchant's web site, if any, for a variety of reasons. 
First, service provider server 104A or 104B accesses the merchant data through the "back door" 
to the merchant's web site. As noted elsewhere herein, some of this data is stripped prior to 
reformatting and display at the ATM 108 A or 108B. In addition, any advertising presented to 
the ATM user by the merchant may be different from advertising presented to users of the 
merchant's web site, if any. 

[0056] The methods and system illustrated with reference to Figures 1 A, IB, 2, 3 A, 3B, and 4 
may be used to support many types of transactions between an ATM user and an electronic 
commerce merchant. All such transactions are within the scope of the present invention. The 
following describes some specific exemplary embodiments of the same. 
[0057] EXAMPLE 1 : Prepaid Long Distance Telephone Charges. 

[0058] One exemplary embodiment in which the methods and systems of the present invention 
may be implemented involves a transaction between an ATM user and a merchant that sells 
prepaid long distance telephone service. In this example, the ATM user inserts her card into an 
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ATM machine. The card may be a credit or a debit card. The ATM user may be presented with 
several options on the ATM screen. As illustrated in Figiu*e 5, the user may select a banking 
option by pressing the "Banking" key 502 on ATM screen 508. Alternatively, the user may 
select an electronic commerce option by pressing, for example, the "Shopping" key 504. In 
some embodiments, the user may not have to insert her card unless the user selects the 
"Banking" option or unless the user indicates her desire to make a purchase. When the 
"Shopping" key 504 is selected, the user is presented with list of products and services that are 
available from various electronic commerce merchants, such as those supported by merchant 
server 102 of system lOOA or lOOB. In some cases, the products and services available to the 
user may be limited, based on, for example, the user's card. For example, a mother may give her 
son a card that enables only the purchase of prepaid long distance charges and, then, only for 
amounts not exceeding $20. Thus, in this example, the son may not be presented with the option 
of prepaying for long distance in an amount that exceeds $20, or for that matter, to purchase 
movie tickets as described in Example 2. 

[0059] Once the user selects the "Shopping" key 504, illustrated in Figure 5, the user may be 
presented with ATM screen 601, as shown in Figure 6. The user may choose any of the listed 
products or services shown on ATM screen 601 by pressing the corresponding key. This key 
press initiates the transmission of ATM data to, for example, service provider server 104A or 
104B shown in Figure 1 A or IB. This ATM data may be data corresponding to the selection 
made by the user such as, in this example, the "Prepaid Long Distance" key 610. 
[0060] The ATM data is received at service provider server 104 A and 104B and reforaiatted 
such that the data can be utilized by the server of the merchant that is offering prepaid long 
distance service, or hosting this service on behalf of another. The reformatted transaction data 
representing the user selection is then transmitted via the Internet to the server(s) of the prepaid 
long distance merchant. The merchant then responds, via the merchant server 102, by 
transmitting merchant data to the service provider server(s) 104 A or 104B. In this example, the 
merchant data includes a menu of services that are available under the "Prepaid Long Distance" 
option. The merchant data representing the menu items are then reformatted at the service 
provider sender such that the menu can be displayed at the ATM. 

[0061] The reformatted merchant data representing the menu items is transmitted to the ATM 
and displayed on ATM screen 701, as shown in Figure 7. The ATM user selects the desired 
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product, such as 40 minutes of long distance time at the rate of $10, by pressing the 
corresponding key 704 at the ATM. Data representing the user's selection is transmitted to and 
received by service provider server. This selection data is reformatted into a format such that the 
data can be utilized by the merchant server(s). The reformatted selection data, representing the 
selection of 40 minutes of long distance time at a rate of $10, is transmitted to the merchant 
server. Because this transaction involves a purchase, the account information of the user is 
verified and payment for the purchase is processed as described above with reference to Figures 
3 A, 3B and 4. In this example, a receipt may be issued at the ATM, confirming the user's 
selection. 

[0062] EXAMPLE 2: Movie Tickets 

[0063] Another exemplary embodiment in which the methods and systems of the present 
invention may be implemented involves a transaction between an ATM user and a merchant that 
sells tickets to events such as movies. The ATM user initiates the transaction in the same way 
described in Example 1. In this example, the user selects key 604 for "Movie Tickets", with 
reference to Figure 6. In response to the user's selection of "Movie Tickets", a selection of 
movies is displayed on ATM screen 801 as shown in Figure 8. The ATM user may, in response, 
select a particular movie. Data representing the user's selection of a particular movie is 
transmitted to the service provider. This data is reformatted such that it may be utilized by the 
merchant server and then transmitted to the merchant server. The data transmitted may also 
contain location information, indicating to the merchant the locations at which the selected 
movie is showing that are of interest to the user. The location data may be data inputted by the 
user, such as a preferred postal zip code, or may be the location of the ATM being used in the 
transaction. 

[0064] The merchant then processes the reformatted data and transmits data representing a 
menu of available theatres at which the selected movie (for example, "RUGRATS IN PARIS") is 
pla3dng. If the data transmitted to the merchant server contains location data, the merchant may 
provide a menu of available theatres that are proximate the location. The data containing the 
menu of theatres is received at the service provider server and reformatted to enable display of 
the menu at the ATM. An exemplary menu of theatres is shown on ATM screen 901 of Figure 9. 
After reviewing ATM screen 901 of Figure 9, the user may be satisfied that it has received all of 
the information that it requires. For example, the user may have wanted to know what movie 
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was playing and where a particular movie was playing, but did not want to purchase tickets. In 
that instance, the user may terminate the transaction without making a purchase. Alternatively, 
the iterative process may continue, prompting the user to select, for example, the theatre, show 
times, number of adult tickets desired, and number of child tickets desired, as shown in Figures 
9, 10, 1 1 and 12. Upon completion of the tickets purchasing transaction, the settlement process 
is completed as described previously. In addition, the user may be presented with a transaction 
confirmation screen 1301, as illustrated in Figure 13. The same confirmation data presented on 
the ATM screen may also be printed on a receipt for presentation at the theatre chosen by the 
user. 

[0065] The following Figures 14-19 describe in detail the process for reformatting the data that 
is transmitted between the ATM and the service provider server, on the one hand, and merchant 
server and the service provider server, on the other hand. 

[0066] Figure 14 illustrates the steps of a method for facilitating communication of information 
related to an electronic commerce transaction via a global conamunications network between an 
ATM and an electronic commerce merchant server (for example, between ATM 108 A or 108B 
and merchant server 102 via global communications network 110 of Figure 1 A or IB) in 
accordance with a preferred embodiment of the present invention. In step 1402, first transaction 
data is received from the electronic commerce merchant at a first server in a first format. Thus, 
for example, transaction data may be received from merchant server 102 by service provider 
server 104 shown in Figures 1 A and IB. The first transaction data is received in a format such 
that it may be utihzed by a server located on a global commxmications network (e.g., in XML 
format). In step 1404, the first transaction data is reformatted. In some embodiments, a subset 
of the first transaction data is selected for reformatting. For example, the data received by 
service provider server 104A or 104B from merchant server 102 may include data that is not 
necessary for carrying out a particular electronic commerce transaction at the ATM; thus, this 
extra data is stripped by service provider server 104A or 104B prior to reformatting. 
[0067] The process of reformatting includes adding a number of different tags to the first 
transaction data. One of ordinary skill in the art will appreciate that the names given to the tags 
herein is for ease of identification only and that the tags may be given different names, but have 
the same or equivalent functionality, and fall within the scope of the present invention. Thus, in 
an exemplary embodiment, an XML declaration is added to the first service provider transaction 
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data, as well as a vendor tag, which includes a merchant name, thereby allowing service provider 
server 104 to associate a particular message with a particular electronic commerce merchant. In 
the preferred embodiment, one or more message tags are added to the first transaction data. The 
message tag(s) are used to instruct the ATM to perform one or more functions relating to the 
electronic commerce transaction. Each message tag may include an identification attribute, 
which holds the unique identifier for each message tag and which is used for internal message 
navigation. 

[0068] In addition, the message tag(s) added in step 1404 may include a number of sub-tags. 
For example, the message tag(s) may include one or more choice tags, which associate a key 
press on the ATM with a selection related to the electronic commerce transaction. For example, 
with reference to Figure 6, a choice tag would enable association of key press 610 on the display 
screen 601 of ATM 108 with selecting "Prepaid Long Distance". The choice tag(s) may further 
include one or more link tags, which associate a uniform resource locator ("URL") (i.e., a 
bookmark within a page or a fully quaUfied URL) with the selection. In addition, the choice 
tag(s) may include a label tag, which contains the string that will be displayed along with the 
selection and may contain formatting data. The choice tag(s) may also include one or more data 
tags. The data tag(s) are used to transmit data relating to the transaction and include a nametag 
for identifying the data. The data tag(s) may also include a value tag, which identifies value data 
associated with the nametag. Where the value tag is empty or is self-closing, it is indicating a 
request for data. For example, with reference to Figure 7, the choice tag, which enables the 
selection, may contain an empty value tag, thus indicating a request for data (such as $5.00) to 
associate with the selection. 

[0069] The message tag(s) added in step 1404 may also include one or more header tags, used 
to hold more detailed information about the message, such as message type information, and 
including necessary transaction control and card formatting data. For example, the header tag(s) 
may include a name tag, which contains a text to be used as a title to the ATM screen, as 
illustrated in Figure 6 by the text "Please select a service." The header tag(s) may also include 
one or more timer tags, which force navigation upon an occurrence of a predetermined time 
lapse. The timer tag may include a link tag, identifying the location of the information (e.g., 
using http: or c:) that will be displayed on the ATM screen upon the lapsing of a predetermined 
amount of time, identified by a timerperiod tag. For example, this may be useful where the 
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content of a nametag is an advertising banner. It may be desirable to have this banner appear 
temporarily on the ATM screen. This temporal display is achieved by assigning the timer tag 
value equal to the amount of time the banner would be displayed. The header tag(s) may also 
include a title tag, which contains a text string that may include flat text or a formatting element 
and one or more data elements (e.g., date and time). 

[0070] The message tag(s) may also include one or more receipt tags, used to identify 
information that is to be printed on a receipt. For example, the receipt information may contain 
information indicating how many tickets were purchased, at what price, and for which movie. 
Figure 13 illustrates the ATM screen display of information that may be printed on a receipt. 
The receipt tag(s) may also include one or more cut tag(s), indicating when a receipt should be 
cut at the ATM. Li the preferred embodiment, the receipt tag(s) are used in conjunction with 
another tag such as a choice tag or specified timer within the header. 

[0071] Further, the message tag(s) may include one or more infotext tags, used to identify the 
main descriptive block of text to be displayed on the ATM. The infotext tag(s) may be flat text 
with certain formatting elements. The infotext may include an input tag, as discussed more fully 
below. One or more footer tags, used to identify information that may be displayed at the bottom 
of the ATM display screen, may also be included in the message tag(s). Like the infotext tag(s), 
the footer tag(s) may include flat text with certain formatting elements. Also, one or more 
serverdata tags may be included in the message tag(s) to identify administrative transaction data. 
In the preferred embodiment, the serverdata tag(s) are populated with data inserted by the service 
provider server, not by the user of the ATM. For example, this tag may hold the zip code of the 
ATM location, other identifying information about ATM or an electronic commerce transaction 
identification number. 

[0072] Retuming again to the flow chart depicted in Figure 14, in step 1406, the reformatted 
first transaction data is transmitted to the ATM. The reformatted first transaction data is capable 
of being utiUzed by the ATM without use of a browser (e.g., an Internet browser) due to the 
reformatting of the data. 

[0073] With reference to Figure 1 5 A, an exemplary message tag is shown. Vendor tag 1 502 
identifies the merchant associated with the message, in this example, "yourdotcom.com". 
Message identification tag 1503 identifies that this message is associated with card 1 (as 
discussed below in more detail with reference to Figure 16). Header tag 1504 includes nametag 
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1505 and title tag 1506 indicating on the ATM screen to the user "Please make your selection." 
Footer tag 1507 displays the name of the merchant, 'Vww.yourdotcom.com", at the bottom of 
the ATM display screen, Serverdata tag 1508 is populated by server provider server 104 and 
includes data tag 1509 through which a request for the ATM zip code (identified by name tag 
1 5 1 0) is made by way of self-closing value tag 1 5 1 1 . Choice tag 1 5 1 2 includes link tag 1 5 1 3 
and label tag 1 5 1 4, as well as data tag 1 5 1 5 . Choice tag 1 5 1 2 thus allows for the presentation of 
the label "$1 Gift" on the ATM display screen next to a particular button/key press on the ATM 
and associates this key press with a value of 1 and the link ' Vww.yourdotcom.com\gcvalue.asp". 
Similarly, choice tag 1516 includes link tag 1517, label tag 1518 and data tag 1519. Choice tag 
1516 thus allows for the presentation of the label "$2 Gift" on the ATM display screen next to a 
particular button/key press on the ATM and associates this key press with a value of 2 and the 
link "www.yourdotcom.com\gcvalue.asp". The output of the exemplary message tag on the 
ATM display screen shown in Figure 15 A is shown in Figure 15B. Figure 15 C provides an 
additional example of a message tag. 

[0074] Assuming, in the example shown with reference to Figures 15A and 15B, the $1 Gift 
was selected, the response from the ATM is shown with reference to Figure 15D. The response 
can be made, for example, using http get protocol, as shown in http get protocol response 1520, 
or using http post protocol, as shown in http post protocol response 1522. 
[0075] Another example relating to prepaid long distance phone cards is shown with reference 
to Figures 15E-15H. 

[0076] With further reference to Figure 14, in a preferred embodiment, in step 1408, second 
transaction data is received from the ATM 108 A or 108B at service provider server 104A or 
104B, in a second format. The second transaction data is capable of being interpreted by the 
ATM. In step 1410, the second transaction data is reformatted, which includes adding to the 
second transaction data one or more request tags. The request tag(s) are used to indicate to the 
merchant server 102 a user selection (e.g., a key press or navigation) relating to the transaction 
and include one or more data tags, as described above. A request tag is used when https post 
protocol is required. In step 1412, the reformatted second transaction data, capable of being 
utihzed by the Internet server, is transmitted to the merchant. Figure 15G provides an example of 
a request header tag 1524. 
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[0077] As shown further in Figure 14, in the preferred embodiment, in step 1414, third 
transaction data is received from the merchant server 102 at the service provider server 104 A or 
104B, in the first format. In step 1416, the third transaction data is reformatted, which includes 
adding to the third transaction data one or more responsedata tags. The responsedata tag(s) 
indicate information from the merchant in response to the user selection. In step 1418, the 
reformatted third transaction data, capable of being utilized by the ATM, is transmitted to the 
ATM. Thus, for example, the responsedata tag would be used by merchant server 102 to pass 
back to ATM 108 A or 108B return data, through service provider server 104A or 104B, without 
passing any screen or receipt information. An example of responsedata tag 1526 is shown in 
Figure 15H. 

[0078] Figure 16 shows the steps of a method for facilitating an electronic commerce 
transaction occurring over a global communications network between an electronic commerce 
merchant and a user of an ATM in accordance with a preferred embodiment of the present 
invention. The ATM includes a display screen and one or more keys for indicating a selection 
relating to said transaction, exemphfied in Figure 8. In step 1601, offer data associated with the 
transaction is formatted for presentation at the ATM. As shown in Figure 17 (step 1601), the 
formatting includes adding one or more card tags, step 1702 and navigation tags, step 1704. The 
formatting step also includes modifying an input tag associated with the data, in step 1 706. 
[0079] The card tag(s) are associated with one or more cards and facilitate display of 
transaction information on the display screen. Each card is enclosed within card tags and, 
optionally, has title and identification attributes. The title attribute indicates the title to be 
displayed at the top of the ATM display screen. The identification attribute is used to identify 
each card and enables linking from one card to another. The card tag(s) ftirther specify content 
(such as text and graphics information) to be displayed on the ATM display screen and the layout 
and format of such content. Graphics may be displayed, including the source of the graphic to be 
displayed within an image tag. An altemate attribute may be included within the image tag to 
identify the image to be displayed in the event the source is not available. In addition, the card 
tag(s) may specify information relating to any receipt to be printed, such as the text to be printed 
on the receipt and cutting the receipt. 

[0080] The navigation tag facilitates navigation within or between cards and within the global 
communications network. Thus, for example, the navigation tag allows for the identification of a 
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particular key on the ATM, association of that key with a label on the ATM display screen, and 
further association of the key with linking information. The Unking information allows for 
display of information associated with a position within a card to which the user has linked or 
within a different card to which the user has linked upon the user's depression of an associated 
key. In addition, the linking information allows for display of information associated with a 
URL upon the user's depression of a key associated with the URL. Thus, a link to a URL is 
quahfied with the server name and the appropriate protocol, for example, 
"http://www.merchant.com/index.asp". All links to servers are preferably transmitted through 
service provider server 104 A or 104B. A link to or within a card should be preceded by a place 
holder, such as "#", for example "#anothercard". 

[0081] Other tags may be used within a card to control navigation. For example, certain tags 
may be used to cause the occurrence of a specific action upon the expiration of a specified time 
period. Another tag may faciUtate redirection of the ATM to another page. 
[0082] The input tag facilitates acceptance of one or more input variables from the user. This 
input tag specifies the manner in which input will be accepted firom the user and passed to the 
service provider server 104 A or 104B during the http requests. The input tag includes a name 
attribute, which identifies the name of the variable to set with the result of the user's text input. 
In addition, the input tag may include a type attribute indicating, for example, whether the input 
will be text (echoed on the ATM display screen as the user types) or a password (echoed on the 
ATM display screen in an obscured form as the user types). Further, the input tag may include 
variable format information. This formatting information may include input mask information, 
indicating whether the characters are uppercase, alphabetic, punctuation, numeric, the number of 
characters, as well as the next character in the field. In addition, the formatting information may 
indicate whether an input element of zero length is acceptable and whether there exists a default 
value for the field. The formatting information may fiirther include maximum number of 
characters, and the minimum or maximum numerical value of the input. 
[0083] The transmission of data within a card tag may be sent securely using, for example. 
Secure Socket Layer ("SSL") protocol. The commencement of a SSL communication is 
indicated by an "https" flag within the navigation tag. Several items of information are 
preferably sent in a secure commimication, such as the user's debit or credit card number, 
expiration date, name, and PIN data. In addition, the particular ATM may have a unique 
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identifier, which also may be included in the communication. Furthermore, each transaction 
using the methods of the present invention may have a transaction serial number, which may be 
included in the communication. The ATM 108 A or 108B will store the transaction serial number 
for joumaling and sending to service provider server 104 A or 104B when the transaction reply is 
received by the ATM 108 A or 108B. Preferably, the https request will include the value of the 
transaction. This will enable the logging of a transaction value against the merchant server 102 
as discussed more fully with reference to Figure 4. 

[0084] Thus, referring again to Figure 16, assuming the user responds to the offer presented on 
the ATM, the user response is received in step 1602. In step 1608, the data relating to the user's 
account (e.g., card number), data relating to the value of the transaction (e.g., the transaction 
price associated with the product/service purchased by the user) and transaction identifier data 
are formatted. The formatting step includes adding to the user account data a secure navigation 
indicator. In step 1610, the formatted user account data, transaction value data and transaction 
identifier data is transmitted to the merchant via the global communications network. After 
receiving this data, merchant may confirm the transaction to the user, which is received in step 
1611. In this case, in step 1612, confirmation data is formatted by, for example, adding to the 
confirmation data a transaction status tag. The transaction status tag indicates the status .of the 
transaction (i.e. authorized or declined) and, preferably, identifies the transaction serial number 
assigned by ATM 108 A or 108B and the merchant server 102 identification number. In step 
1614, the formatted confirmation data is transmitted to the ATM. 

[0085] In the preferred embodiment, once the transaction reply (described with reference to 
Figure 15H) is received firom merchant server 102 at ATM 108 A or 108B, ATM 108 A or 108B 
may log the success or failure of the transaction with service provider server 104A or 104B, The 
transaction reply may contain an exit tag, indicating that control should be returned to the ATM 
application. In other embodiments, however, chained transactions are available. 
[0086] Other miscellaneous tags may be used with the methods and systems of the present 
invention. For example, service provider server 104A or 104B may retrieve cached data relating 
to the electronic commerce transaction from merchant server 102 at a particular time period. In 
addition, service provider server 104A or 104B may upload journal files at a particular time of 
the day. Each of these time periods may be set within a configuration tag using a download time 
element. 
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[0087] Figure 18 shows an example of a series of tags that may be used in connection with a 
transaction for offering and subsequent purchasing of a book at an ATM. Card tag 1802 includes 
the identification attribute 1801, in this case "authors", of this particular card. Text tag 1804 
shows the text "SELECT AN AUTHOR YOU ARE INTERESTED IN:" centered in area 1 of 
the card. Go tag 1808 of navigation tag 1806 provides for the assignment of "fkeyl", labeled 
"JANE AUSTIN>", to card 1807, identified "janea" through do tag 1810. The way in which the 
text of this card is displayed on the ATM display screen is shown in display area 1811. Within 
the card 1814 identified "janea", go tag 1809 allows the user to submit the http request shown 
upon selection of the key "fkeyl" labeled "PRIDE & PREJUDICE>" on the ATM. Display area 
1812 shows the text of card 1814 as displayed on the ATM display screen. Exit tag 1813 
indicates the end of the electronic commerce transaction and returns control to the ATM. 
[0088] Figure 19 shows an example of data, which may be returned from service provider 
server 104 upon, for example, the user selecting a book in the example shown in Figure 19A. 
Within card 1930 is the status (in this case "authorize"), as well as the identification nimibers of 
the merchant, the server and the serial number. Text tag 1936 displays on the ATM display 
screen "PLEASE WAIT FOR YOUR RECEIPT" shown on exemplary screen 1937. Receipt tag 
1934 indicates the printing of text on the receipt 1936. 

[0089] While the invention has been described in detail and with reference to specific 
embodiments thereof, it will be apparent to one skilled in the art that various changes and 
modifications can be made therein without departing from the spirit and scope thereof For 
example, the specific names of the tags provided herein are given by way of example and not 
limitation. Tags with similar ftinctionality may be given different names within the scope of the 
present invention. Thus, it is intended that the present invention cover the modifications and 
variations of this invention provided they come within the scope of the appended claims and 
their equivalents. 
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